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Description of Cisco Systems’ Subnet Allocation Option for DHCPv4 
Abstract 


This memo documents a DHCPv4 option that currently exists and was 
previously privately defined for the operation and usage of the Cisco 
Systems’ Subnet Allocation Option for DHCPv4. The option is passed 
between the DHCPv4 Client and the DHCPv4 Server to request dynamic 
allocation of a subnet, give specifications of the subnet (s) 
allocated, and report usage statistics. This memo documents the 
current usage of the option in agreement with RFC 3942, which 
declares that any preexisting usages of option numbers in the range 
128-223 should be documented and that the working group will try to 
officially assign those numbers to those options. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6656. 
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Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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Les 


Introduction 


This memo documents a DHCP option [RFC2132], the Subnet Allocation 
option, that was developed by Cisco and allows a DHCP Client to 
allocate a subnet given information from a DHCP Server. This 
protocol makes use of DHCP option number 220, one of the option 
numbers reclassified by [RFC3942]. That RFC specifies in Section 4, 
procedure 2, "Vendors that currently use one or more of the 
reclassified options have 6 months following this RFC’s publication 
date to notify the DHC WG and IANA that they are using particular 
options numbers and agree to document that usage in an RFC". This 
memo serves as that documentation. The DHC WG has had no input into 
any of the details of the protocol operation and makes no statement 
about the correctness or any other aspect of the protocol. The WG 
also has seen no interest in further implementation or deployment of 
this protocol other than privately, and therefore has decided to 
publish this document solely for informational purposes. 


The Subnet Allocation option provides a straightforward way to 
allocate a subnet from DHCP, useful for a simple Dial-in Aggregation 
box, or to implement a Hierarchical chain of DHCP Servers, each one 
in turn leasing one or more subnets to the next DHCP Server down the 
chain. This option is specified in such a way as to use one DHCP 
option number, while using suboption numbers for each function. 


Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document also uses the following terms: 


DHCP Client:  DHCP Client or "Client" is an Internet host using DHCP 
to obtain configuration parameters such as a network address. 


DHCP Server: ADHCP Server or "Server" is an Internet host that 
returns configuration parameters to DHCP Clients. 
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3. Subnet Allocation Option Format 


0 1 2 

0 1.2.3.4 5 6 7.9 90 1.2 3.4.5 6 7 8 9.0 1 2.3-4 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

| Code | Len | Flags | Suboptions 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


Code = Subnet Allocation option code (1 octet): 220 
Len = Length of the entire option including all suboptions 
(1 octet) 


Flags = Various flags: (None currently defined) 
One or more suboptions may be specified as described below. 
3.1. Subnet-Request Suboption Format 


0 T 2 3 
Q0 1.2: 3-4 9.6 7 9.9.0 12 3.4.5 6 7 8 9-0 Ll 2. 3-45 6 7-9. 9.0 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
A | Len | Flags :i:h| Prefix 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Len = Length of the suboption (always 2 for this suboption) 
(1 octet) 
Flags = Flags field. (all unused bits must be zero) 


'h' = Hierarchical flag 
1: Client will be allocating addresses from this subnet. 
0 : Client will be relaying DHCP requests to the Server 
from this subnet. 
‘i’ = Information flag 
1: Client is seeking information about previously 
allocated subnets. 
0: Client is seeking a new subnet allocation. 


Prefix = Network prefix length requested 
(0 means no suggested length is given) (1 octet) 


The DHCP Server SHOULD NOT include the Subnet Request suboption in 
any replies to the DHCP Client. Enough information will be present 
in the Subnet-Information suboption, such that the Subnet Request 
suboption is not needed in replies to the Client. 


The DHCP Server SHOULD allocate a subnet with prefix length [RFC4632] 
less than or equal to the "Prefix" field length specified in the 
request. In other words, a subnet containing a number of addresses 
at least the size indicated by the prefix length requested and 
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possibly more. The DHCP Server MAY allocate a subnet with a prefix 
length greater than that specified in the request (or a subnet with a 
number of addresses less than requested), but this is not encouraged. 


A "Prefix" field size of 0 MAY be specified by the DHCP Client. In 
this case, no suggested prefix length is given. 


Multiple Subnet-Request suboptions in a DHCP packet indicate that 
multiple subnets are being requested. Note that multiple occurrences 
of this suboption MUST NOT be concatenated in the sense of [RFC3396]. 


Each Subnet-Request suboption MUST result in no more than one Subnet- 
Information suboption in the DHCPOFFER message from the Server, and 
may result in no Subnet-Information suboptions. 


The Client MAY also include the Subnet-Information suboption in order 
to request a particular subnet. In this case, the Client SHOULD only 
include one Subnet-Request suboption, since it would otherwise be 
unclear which Subnet-Information suboption referred to which Subnet- 
Request suboption. Multiple subnet requests can be made by sending 
multiple DHCPDISCOVER packets. 


Setting the 'h' flag to 1 indicates the Client will be allocating 
addresses from the allocated subnet(s) itself. This can be thought 
of as a "Hierarchical DHCP" design in that control of allocation for 
the subnet(s) will be passed to the Client. 


Setting the 'h' flag to 0 indicates the Client wants the DHCP Server 
to retain control over allocation of addresses from the subnet (s). 
Any address allocation requests on the subnet will be relayed back to 
the DHCP Server. 


Setting the 'i' flag to 1 indicates the Client is NOT seeking 
allocation of any subnets, but is simply seeking information from the 
Server as to what subnet(s) have been allocated (or reserved) for 
this Client. If the 'i' flag is set to 1, then the "Prefix" field 
SHOULD be set to 0 and MUST be ignored by the Server. In this case, 
the conversation between the Client and the Server will only progress 
to the DHCPOFFER packet from the Server, giving the information, as 
described in Section 6 below. 


Any undefined flags (those other than 'i' and 'h', mentioned above) 
should be ignored by the DHCP Server. 
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3.2. Subnet-Information Suboption Format 


0 1 2 
01234567890123456478901234 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
| 2 | Len | Flags :c:s| SP1, SP2, 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


= Length of the suboption (min. length of 8) (1 octet) 
= Various flags that apply to ALL Subnet Prefix 
Information fields specified in this suboption. 
Unused flags must be zero. 


Hp 
= 0 
Y 5 
Q 
n 
Io i 


'c' : Client flag (explained below) 
1: This information is in response to a Client request 
(or has been echoed back by the Client, when asking 
for the next previously allocated subnet from the 


Server). 
0 : Otherwise. 
's' : Server flag (explained below) 
1: Server has additional subnet information for this 
Client. 
0 : Otherwise. 
SP1, SP2, ... Subnet Prefix Information blocks as specified below 


(variable size) 


Setting the 'c' flag to 1 indicates this Subnet-Information suboption 
is in response to a Client request for information from the Server as 
to what subnet (s) have been allocated. This flag is used in response 
to a Subnet-Request suboption with the 'i' flag set and should be 0 
in other Server responses. Note, the flag is echoed back from the 
Client to the Server when requesting the "next previously allocated 
subnet". Another way to think of the 'c' bit would be that it 
indicates that the subnet information contained in this suboption 
does not represent a new allocation by the Server or a new request 
for allocation by the Client, but instead represents previously 
allocated subnet information. 


Setting the 's' flag to 1 indicates the Server has additional subnet 
information for the Client. 


Any undefined flags (those other than 'c' and 's', mentioned above) 
should be ignored by the DHCP Server. 
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The Subnet-Information suboption is used by the DHCP Server in order 
to return information as to what subnets are offered (in the case of 
a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). 
As is indicated above, multiple subnets may be returned in one 
Subnet-Information suboption. 


The Subnet-Information suboption is also used by the DHCP Client in 
order to request allocation of specific subnets in a DHCPREQUEST 
packet. In this case, the "Network", "Prefix", and "Flags" fields 
contained in the associated Subnet Prefix Information blocks MUST NOT 
be changed from the information that was received in the DHCPOFFER 
packet from the Server. The Client MAY, however, use multiple 
Subnet-Information suboptions in order to request subnets that were 
originally specified by the Server inside one Subnet-Information 


suboption. 
3.2.1. Subnet Prefix Information Block Format 
0 1 2 3 


01 2-3 4-5 06.73 38 09-0 Ts 22053) 4:-5.46- T ;8..9 0^ 3142: 3 M. 5. 652 8; 9 Oh 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Network | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Prefix Flags :h:d| Stat-len | Optional stats... 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Network = IPv4 network number (4 octets) 
Prefix = Prefix length (1 octet) 
Flags = Flags field (Undefined bits must be zero) (1 octet) 
'd' = Deprecate flag (explained below) 
1: Deprecation of this subnet is requested. 


0 : No deprecation is needed. 


'h' = Hierarchical flag (explained below) 
1: Client will be allocating addresses from this subnet. 
0 : Client will be relaying DHCP requests to the Server 
from this subnet. 


Stat-len = Length of the optional statistics information field 
(zero if no statistics are included) (1 octet) 


The 'd' flag may only be returned by the Server to the Client (inside 
a DHCPACK packet, in response to a DHCP RENEW). Its presence means 
that the Client should prepare to give up the subnet. For example, 
if the Client is assigning addresses from this subnet to other 
Clients, it should cease doing so immediately and should not renew 
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any leases when Clients ask for renewal. As soon as all addresses in 
the subnet are unallocated, the Client should send a DHCPRELEASE 
message to the Server, including a Subnet Prefix Information block 
for the subnet in order to release the subnet. The format of this 
message is described farther below. 


The ’h’ flag tells the Client how the Server intends for the Client 
to use the allocated subnet. It is interpreted in the same manner as 
that in the Subnet-Request suboption. In response to a Subnet- 
Request, the Server should normally specify the 'h' flag in the same 
manner as it was in the Subnet-Request suboption from the Client. 

The Server MAY, however, change the 'h' flag from that specified in 
the Subnet-Request suboption if it has been configured to override 
the Client's request. 


Any undefined flags (those other than 'd' and 'h', mentioned above) 
should be ignored by the DHCP Server. 


If any usage statistics information is to be included, then the 
"Stat-len" field specifies the number of bytes of statistics 
information that is included. See below for more information. If no 
statistics information is included, then this byte MUST be zero. The 
"Stat-len" field SHOULD always be zero when this suboption is sent by 
the DHCP Server. The usage statistics information is intended for 
use only to report usage statistics from the Client to the Server. 


3.2.1.1. Subnet Usage Statistics 


The Subnet-Information suboption may also include usage statistics 
information. If this information is included, then the "Stat-len" 
(Statistics length) field MUST be set to the number of bytes of 
statistics information that is being included. The statistics 
information MUST be in the following form and order: 


0 1 

Qi d, .2 3,4 5.6- Y .8. 9-0. 2 3.4:5 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
High water 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

Currently in use 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 
Unusable 

一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


+ 一 + 一 + 一 十 
+ 一 + 一 + 一 十 


"High water" refers the to "high-water mark" of allocated addresses 
within the subnet. That is, the largest number of addresses that 
were ever allocated at one time from the subnet. 
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"Currently in use" refers to the number of addresses currently 
allocated in the subnet. 


"Unusable" refers to the number of addresses that are currently 
unusable for any reason (such as a Client returning a DHCPDECLINE, or 
finding the address already in use). 


Additional statistics may be added to this option in the future. If 
so, they MUST be appended immediately after the already defined 
statistics fields. All statistics fields MUST remain in the same 
order. Use the all ones value (Oxffff) in order to skip reporting a 
number for a particular field. Fewer fields may be included than 
what is specified above; for example, if "Stat-len" is "4", then the 
"Unusable" field has not been included. All fields that are included 
MUST remain in order specified here. 


3.3.  Subnet-Name Suboption Format 


0 I 

0'1 2..3. 4-5 6 7 5989.0 1| 2..3 4 5.6 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 

| 3 | Len | Name 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


Len = length of the suboption (min. length of 1) (1 octet) 


The Subnet-Name suboption may be used in order to pass a subnet name 
to the Server for use during allocation. This name may be used for 
any purpose but is intended to tell the Server something extra about 
the needed subnet; for example, "sales department", "customer 1002", 
"address pool FOO", or some such. The "name" should NOT be NULL 
terminated since the "len" field already specifies the length of the 
name. The "Name" in this suboption MUST be given using UTF-8 
[RFC3629]. 


3.4. Suggested-Lease-Time Suboption Format 
0 1 2 3 


01234567890123456789012345678901 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 4 | Len (4) | ti | t2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| t3 | t4 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Len = length of the suboption (always 4 for this suboption) (1 
octet) 
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4. 


4. 


The Suggested-Lease-Time suboption MAY be included by the Server in 
order to suggest the lease time to be used by the Client when 
allocating addresses from the subnet allocated. The 4-octet value of 
the lease time is in the same format as that of the "IP Address Lease 
Time" option (option 51), as described in [RFC2132]. 


If included, this suboption MUST appear only once. (Inclusion of 
multiple such suboptions would result in ambiguity as to which 
applied to which subnet.) If different suggested lease times are 


needed, the Server SHOULD, instead, reply with only one offered 
subnet and should set the "Server flag" in the Subnet-Information 
suboption to indicate to the Client that it should send another 
subnet request to gather the others. 


The Client SHOULD use a lease time, when allocating addresses from 
the subnet, that is the lesser of the remaining lease time of the 
subnet itself and the Suggested-Lease-Time suboption. 


Requesting Allocation of a Subnet 
1. Client DHCPDISCOVER Message 


The DHCP Client creates a DHCPDISCOVER message including the Subnet 
Allocation option, and its set of suboptions, to request allocation 
of a subnet. The DHCP Client should include the Subnet-Request 
suboption, specifying the prefix length of the subnet requested. The 
'h' bit should be set to 1 if the Client intends to control 
allocation of addresses within the subnet itself, or 0 if the Server 
should retain control of addresses within the subnet. More than one 
Subnet Allocation option may appear in a DHCPDISCOVER message; 
however, the Client SHOULD limit the number of requests, noting that 
the DHCP replies will need to include the Subnet-Information 
suboption, which takes up more space than the Subnet-Request 
suboption. 


If more than one subnet is being requested, multiple Subnet-Request 
suboptions MAY be included or multiple DHCPDISCOVER messages MAY be 
sent instead. The prefix length field of each Subnet-Request 
suboption MUST be either 0, or in the range of 1 to 30 inclusive. 


The DHCP "IP address lease time" option (code 51) MAY be included in 
the DHCPDISCOVER message to specify the lease time the Client is 
requesting for the subnet. If not present, no suggested lease time 
is given. 


The DHCP "Client ID" option (code 61) MAY be included in the 
DHCPDISCOVER message as it may be used by the Server in performing 
the subnet allocation. 
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4.2. Server DHCPOFFER Message 


Upon receiving a DHCPDISCOVER containing the Subnet Allocation 
option, the DHCP Server SHOULD respond with a DHCPOFFER message 
including the Subnet-Information suboption in order to specify the 
subnet(s) that it is willing to allocate to the Client in order to 
fulfill the request(s). 


The Server need not reserve the subnets that are being offered, but 
SHOULD not offer the same subnets to another DHCP Client until a 
reasonable time period (implementation dependent) has passed. (This 
is similar to normal DHCP address allocation.) 


The Server MUST NOT include the Subnet-Request suboption in the 
DHCPOFFER. The same information is already present in the Subnet 
Information suboption(s) that SHOULD be included in the DHCPOFFER. 


The Server SHOULD also include the IP address lease time option 
(option 51) in the DHCPOFFER message. This gives the lease time for 
all subnets given in all Subnet-Request suboptions contained in the 
DHCPOFFER message. The Server MAY also include the Renewal and/or 
Rebinding options in order to further control the "T1" and "T2" lease 
timers of the Client. There MUST be exactly one IP address lease 
time (and optionally one Rebinding and/or one Renewal option) in the 
DHCPOFFER message. 


The Server MAY set the "Server flag" ('s') to 1 to indicate that it 
would like to allocate one or more additional subnet(s) to the 
Client. This indicates that the Client should send another 
DHCPDISCOVER message specifying a prefix length field, P, of zero in 
order to request the additional subnet allocation(s) information. 
This may be necessary if the subnets are to be allocated with 
different lease times, for example. 


The "Client flag" ('c') MUST be set to 0 to indicate this is a Server 
response to a Client request for a new subnet allocation and not a 
response to a request for information about already allocated 
subnets. 


If the packet contains a Subnet Allocation option, the Server SHOULD 
set the DHCP yiaddr value to all zeros (0.0.0.0) and the Client MUST 
ignore fields having to do with address assignment. In other words, 
a DHCP packet exchange cannot provide subnet allocation and address 

assignment simultaneously. 
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4.3. Client DHCPREQUEST Message 


When sending a DHCPREQUEST, the Client MUST NOT modify any fields of 
any Subnet-Information suboptions received from the Server. However, 
the Client MAY choose not to include some Subnet-Information 
suboptions when issuing the DHCPREQUEST.  Subnet-Request suboptions 
MUST NOT be included in the DHCPREQUEST message; only the Subnet- 
Information suboption(s) should be included. 


4.4. Server DHCPACK Message 


The DHCP Server, upon receipt of the Client's DHCPREQUEST message, 
MAY refuse allocation of any subnets (for example, if they have been 
allocated elsewhere in the meantime); however, since the Server 
should have set aside the subnets offered for a short period of time, 
and since the Client should have requested the subnets within a short 
period of time after receiving the offer(s) from the Server(s), this 
last minute rejection should be rare. The DHCP Server MUST NOT 
change the network number(s) or prefix length(s); however, it MAY 
remove some Subnet-Information suboptions from the list. 


The Server SHOULD include the IP address lease time option specifying 
the lease period for all subnet(s) in the DHCPACK. All subnets 
allocated in one DHCP message will have the same lease time, and only 
one IP address lease time option must appear in the DHCP message. 


If the Server has internal information that states that the Client 
should be allocated more subnets than were requested, the Server MAY 
set the 's' bit in the last Subnet-Information suboption to indicate 
that the Client needs to request more subnets (as described above). 


The allocable unit is the tuple (network number, prefix length). 
Multiple subnets may be allocated in one DHCPACK; however, since 
there can be only one Lease-time option, each subnet allocated is 
assigned the same lease time. Each subnet lease tuple (network 
number, prefix length) MAY be renewed or released individually. 


5. Client Renewal of Subnet Lease 
Dala Client RENEW DHCPREQUEST Message 


The Client MUST renew all subnets allocated with a lease time in much 
the same manner as renewing an allocated IP address. Renewal timers 
need not be set in exactly the same manner, however. If Renewal 
and/or Rebinding options were included in the DHCPACK of the subnet 
allocation, then these "T1" and "T2" timers should be used just as 
they would be in the case of address allocation timers. 
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The DHCPREQUEST message MUST include a Subnet-Information suboption 
for which the Client is seeking renewal of the lease. This Subnet- 
Information suboption may optionally include subnet usage statistics, 
as described above in Section 3.2 ("Subnet-Information Suboption 
Format"). 


The subnet network number field ("Network") and subnet prefix length 
field ("Prefix") MUST agree with the values as they were originally 
allocated to the Client by the Server. In any of the statistics 
fields (High water, Currently in use, Unusable), a value of all ones 
(Oxffff) SHOULD be used if the Client has no information to report 
for a statistic. 


5.2. Server RENEW DHCPREQUEST Response 


The Server MAY respond to a subnet RENEW with either a DHCPACK or 
DHCPNAK response. If a DHCPNAK response is given, the Client MUST 
immediately stop using the subnet(s) specified and, if possible, 
notify all Clients with addresses allocated from this subnet that 
their addresses are no longer valid. The Client MAY, of course, send 
a DHCPDISCOVER message containing the Subnet Allocation option and 
the Subnet-Request suboption in order to acquire another subnet for 
use. In general, the Server should ask the Client to deprecate 
subnets by using the 'd' bit of the Subnet-Information suboption in a 
DHCPACK message (see below). 


If a DHCPACK response is given, the "Deprecate" ('d') bit of the 
Flags field in the Subnet-Information suboption may also be set. 

This indicates the DHCP Client should prepare to stop using this 
subnet. If the Client is allocating IP addresses for other Clients 
from this subnet (e.g., via DHCP), the Client SHOULD immediately stop 
allocating such addresses. Once all allocated addresses in the 
subnet have been released, the Client SHOULD send a DHCPRELEASE 
message, including the Subnet-Information suboption (with optional 
usage statistics) in order to release the subnet(s) back to the 
Server. 


5.3. Client DHCPRELEASE Message 


The DHCP Client SHOULD send a DHCPRELEASE message in order to release 
allocated subnet(s) back to the Server when it is finished using 
them. This message MUST NOT include the Subnet-Request suboption, 
but MUST include one or more Subnet-Information suboptions, and may 
optionally include usage statistics. 


The Client MUST release the same subnet(s) of the same prefix length 


("Prefix"), as were originally allocated. The Client MAY release a 
subset of the subnets that were allocated originally. In other 
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words, the allocable unit is the tuple (network number, prefix 
length). Multiple subnets may be allocated in one DHCPACK; however, 
each subnet MAY be released individually. 


5.4. Server DHCPFORCERENEW Message 


The DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message 
containing the Subnet Allocation option and the Subnet-Information 
suboption. Upon receiving this message, the DHCP Client MUST issue a 
DHCPREQUEST message to the DHCP Server in order to renew the lease on 
the subnet mentioned. No other subnets allocated to the Client are 
affected. As is the case with all DHCP RENEW messages, the Client 
may include subnet usage information in the Subnet-Information 
suboption in order to report subnet usage statistics, or set the 
"Stat-len" field to 0 if no statistics are to be reported. 


If the Server responds to this DHCPREQUEST with a DHCPNAK message, 
then the Client MUST immediately stop using the subnet(s) and, if 
possible, notify all Clients with addresses allocated from this/these 
subnet(s) that their addresses are no longer valid. The Client MAY, 
of course, send a DHCPDISCOVER message containing the Subnet 
Allocation option and the Subnet-Request suboption in order to 
acquire another subnet for use. 


6. Client Requesting Previously Allocated Subnet Information 


A DHCP Client MAY request from the DHCP Server a list of what subnets 
are currently allocated to the Client. This may be used to recover 
from a restart if the Client does not have local storage in order to 
retain the information itself. (For an example of this, see 

Section 8.2 below.) 


6.1. Initial Client DHCPDISCOVER Message 


The DHCP Client DHCPDISCOVER message, when used to discover already 
allocated subnet information, SHOULD contain a Subnet-Request 
suboption with the "Prefix" field set to 0 and with the 'i' flag set 
to 1 to indicate that the Client is seeking already allocated subnet 
information from the Server. No Subnet-Information suboptions should 
be included in this message. Note, no Subnet-Information suboption 
is included in this message, since the Client would not know of any 
subnet to request at that point. 


This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, 
or broadcast in the normal fashion. 
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6.2. Initial Server DHCPOFFER Response 


Any DHCP Server that has allocated subnets to the Client SHOULD 
respond to the DHCPDISCOVER message with a DHCPOFFER message. The 
DHCPOFFER message should contain one or more Subnet-Information 
suboption(s) telling the prefix of the subnet(s) allocated to the 
Client. 


The Server SHOULD, internally, retain an ordered list of subnets that 
are allocated to each Client. In response to an initial DHCPDISCOVER 
message requesting allocated subnet information (i.e., one with the 
'i' flag set to 1, but not carrying a Subnet-Information suboption), 
the Server returns in the DHCPOFFER message the subnet information 
for the first subnet(s) from this list. If the end of the list has 
been reached, then the 's' bit of the last Subnet-Information 
suboption included in the message MUST be set to 0. If there are 
more subnets in the list, the 's' bit MUST be set to 1 to indicate to 
the Client that more information is available. Since this 
information is in response to a Client request for previously 
allocated subnet information, the 'c' bit MUST be set to 1. 


6.3. Additional Client DHCPDISCOVER Messages 


The Client, upon receiving any Server DHCPOFFER messages containing 


Subnet Information suboption information with the 'c' ("Client") bit 
set, SHOULD gather the network number ("Network") and prefix length 
("Prefix") information from the message. 


If the 's' bit is set in the last of the Subnet-Information 
suboptions included in the message, then the Client SHOULD construct 
a new DHCPDISCOVER message containing the Subnet Allocation option 
and the last Subnet-Information suboption from the Server's message. 
This message SHOULD then be sent back to the same DHCP Server 
originating the DHCPOFFER message. The 'c' and 's' bits MUST retain 
the same settings they had from the Server's DHCPOFFER message and 
the network number ("Network") and prefix length ("Prefix") fields 
MUST be unaltered as well. 


If the 's' bit in all of the Subnet-Information suboptions from the 
Server was 0, then it indicates the Server has no more information 
about subnets allocated to the Client. 


6.4. Additional Server DHCPOFFER Responses 
The Server, upon receiving from a Client an additional DHCPDISCOVER 
message for allocated subnet information retrieval, with the 'i' flag 


set to 1 and containing one or more Subnet Information suboptions 
with the 'c' and the 's' bits set, MUST use the network number 
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("Network") and prefix length ("Prefix") fields contained in the last 
such Subnet Information suboption. This is in order to locate the 
position in the internal table of allocated subnets for this Client. 
Then, the Server MUST return an DHCPOFFER message containing a 
Subnet-Information suboption giving information about the next set of 
subnets allocated to this Client. If this finishes the list in the 
table for this Client, then the 's' bit MUST be set to 0 to indicate 
there is no more information. Any Subnet Information suboptions 
encountered without both the 'c' and 's' bits set should be ignored 
by the Server. 


7. DHCP Server Subnet Allocation Method 
The actual method of allocating subnets on the DHCP Server, as well 
as the configuration of what networks may be subnetted and how, is 
left up to the implementation. 

8. Examples 
Only the Subnet Allocation option and accompanying suboptions are 
displayed in these examples. All other fields in the DHCP messages 
are described in [RFC2131]. 


8.1. Example 1 


A DHCP Client requesting a subnet with prefix length 24 from which 
the Client will allocate addresses to other Clients. The Server 
responds with an allocation of exactly the size requested: 


The Client sends a DHCPDISCOVER message including a Subnet Allocation 
option with the Subnet-Request suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 220 | 5 | 0 | 1 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 [o[o] 24 | 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Server responds with a DHCPOFFER message including a Subnet 
Allocation option with a Subnet-Information suboption, offering the 
subnet 10.0.1.0/24. 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 8 | 0 [ofo] 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 1 | 0 | 24 | [ofo] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Client sends a DHCPREQUEST including a Subnet Allocation option 
with a Subnet-Information suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 8 | 0 [ofo] 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 1 | 0 | 24 | [ofo] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Server responds with a DHCPACK message including a Subnet 
Allocation option with a Subnet-Information suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 8 | 0 [ofo] 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 1 | 0 | 24 | [ofo] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Later, the Client sends a DHCPRELEASE message including a Subnet 
Allocation option with a Subnet-Information suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 8 | 0 [ofo] 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 1 | 0 | 24 | [ofo] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 二 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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8.2. Example 2 
A DHCP Client requesting two subnets, each with prefix length 24: 


The Client sends a DHCPDISCOVER message including a Subnet Allocation 
option with a Subnet-Request suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 9 | 0 | 1 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 0] 0| 24 | 1 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 [ojo] 24 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Server responds with a DHCPOFFER message including a Subnet 
Allocation option with a Subnet-Information suboption: 


The DHCPOFFER specifies one subnet of size 24 and one subnet of size 
28. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 18 | 0 | 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 15 | | 0] 0| 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | | 0] 0| 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 10 | 0 | 3 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 28 | | 0] 0| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Client sends a DHCPREQUEST message including a Subnet Allocation 
option with a Subnet-Information suboption: 


The Client decides that the subnet of size 28 is not sufficient so it 
doesn't include that subnet in the DHCPREQUEST message. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 8 | | 0] | 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | |olol 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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The Server responds with a DHCPACK message including a Subnet 
Allocation option with a Subnet-Information suboption: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | vg | 0 | 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 8 | |o]0| 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | [ojo] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Later, the Client sends a DHCPREQUEST message in order to renew the 
lease on the one subnet and includes subnet usage information. It 
reports that a maximum of 10 addresses were allocated from the subnet 
since the last report, 7 addresses are currently allocated, and 2 
addresses were found to be unusable. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 17 | 0 | 2 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 14 | 1010| 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | 1010| 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 6 | 0 | 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 7 | 0 | 2 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Server responds with a DHCPACK message; however, it signals to 
the Client that the subnet should be deprecated. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 8 | [ojo] 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | [o]1] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
The Client reloads at this point and, upon completion of the reload, 


sends a DHCPDISCOVER asking for information about all subnets that 
were allocated to it. 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 5 | 0 | 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | [1] 0| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Server responds with a DHCPOFFER, giving the subnet information 
about the one subnet that is allocated to the Client. Also, the 
Server specifies that the one allocated subnet should be immediately 
deprecated. Note that the ’s’ ("Server") bit is 0, thus indicating 
that there is no more information available for this Client. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 13. | 0 | 2 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 8 | [1] 0| 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | [o]1] 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


The Client responds with a DHCPRELEASE message after having 
deprecated the subnet: 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| 220 | 11 | 0 | SIS | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 8 | |o]0| 10 | 0 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 2 | 0 | 24 | | 0] 0| 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 0 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

9. Differences from DHCPv6 Prefix Delegation 
The following differences may be noticed between Subnet Allocation as 
described in this document and DHCPv6 Prefix Delegation as described 


in [RFC3633]: 


o This option does not use anything like an "IA PD" as is used in 
DHCPv6. 


o If the Server cannot allocate a subnet, it remains silent, instead 
of returning a special response saying nothing is available. 
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o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ 
prefix usage statistics. 


o DHCPv6 has no equivalent to the "subnet deprecation" flag as 
described here. 


o DHCPv6 Prefix Delegation makes no mention of what Client actions 
should result from receiving a DHCPNAK during a RENEW of a 
delegation. 


o DHCPv6 has no equivalent of the subnet allocation "Network name" 
suboption, which may be used by the Server for various purposes, 
such as to specify a pool to use when allocating a subnet. 


o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet 
Allocation" (setting the 'h' flag in the Prefix Information 
block). There is no v6 equivalent of clearing the 'h' flag, in 
which the Server retains authority over allocation of addresses 
from the subnet. 


o DHCPv6 Prefix Delegation has nothing to correspond to the 
Suggested-Lease-Time suboption. 


10. Security Considerations 


Potential exposures to attack are discussed in Section 7 of the DHCP 
protocol specification [RFC2131]. The Subnet Allocation option can 
be used to hoard all allocable subnets on a network. 


Implementations should consider using the DHCP Authentication option 
[RFC3118] in order to provide a higher level of security if it is 
deemed necessary in their environment. 


11. IANA Considerations 


IANA has assigned DHCP option number 220 for this option, in 
accordance with [RFC3942]. 


No assignment of values for the suboption codes need be made at this 
time. New values may only be defined by IETF Consensus, as described 
in [RFC5226]. Basically, this means that they are defined by RFCs 
approved by the IESG. 
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